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Abstract 
This document specifies a CLASSTYPE object to support Diffserv-Aware 


Traffic Engineering (DS-TE) where path computation is performed with 
the aid of a Path Computation Element (PCE). 
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1. Introduction 
[RFC5440] specifies the Path Computation Element Communication 
Protocol (PCEP) for communications between a Path Computation Client 
(PCC) and a Path Computation Element (PCE), or between two PCEs, in 


compliance with [RFC4657]. 


Diffserv-aware MPLS Traffic Engineering 
fundamental requirement to be able to enforce different bandwidth 
constraints for different classes of traffic. It describes 
mechanisms to achieve per-class traffic engineering, rather than on 
an aggregate basis across all classes by enforcing Bandwidth 
Constraints (BCs) on different classes. 
the associated protocol extensions are specified in [RFC3564] and 
[RFC4124], respectively. 


As per [RFC4657], 


TE-specific constraint. 
does not have the capability to specify the Class-Type in the path 
computation request. 


In this document, 


However, 


(DS-TE) addresses the 


Requirements for DS-TE and 


PCEP must support traffic Class-Type as an MPLS- 
in the present form, PCEP [RFC5440] 


we define a new PCEP object called CLASSTYPE, which 


carries the Class-Type of the TE LSP in the path computation request. 


During path computation, 
bandwidth constraint of the TE LSP. 


Sivabalan, 


et al. 


a PCE uses the Class-Type to identify the 
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1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Terminology 


CT (Class-Type): A set of Traffic Trunks governed by a set of 
bandwidth constraints. Used for the purpose of link bandwidth 
allocation, constraint-based routing and admission control. A given 
Traffic Trunk belongs to the same CT on all links. 


DS-TE: Diffserv-Aware Traffic Engineering. 
LSR: Label Switching Router. 
LSP: Label Switched Path. 


PCC (Path Computation Client): any client application requesting a 
path computation to be performed by a Path Computation Element. 


PCE (Path Computation Element): an entity (component, application, or 
network node) that is capable of computing a network path or route 
based on a network graph and applying computational constraints. 


PCEP Peer: an element involved in a PCEP session (i.e., a PCC or the 
PCE). 


TE-Class: A pair consisting of a Class-Type and a preemption priority 
allowed for that Class-Type. An LSP transporting a Traffic Trunk 
from that Class-Type can use that preemption priority as the setup 
priority, the holding priority, or both. 


TE LSP: Traffic Engineering Label Switched Path. 


Traffic Trunk: An aggregation of traffic flows of the same class 
(i.e., treated equivalently from the DS-TE perspective), which is 
placed inside a TE LSP. 


3. CLASSTYPE Object 


The CLASSTYPE object is optional and is used to specify the Class- 
Type of a TE LSP. This object is meaningful only within the path 
computation request, and is ignored in the path reply message. If 
the TE LSP for which the path is to be computed belongs to Class 0, 
the 
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path computation request MUST NOT contain the CLASSTYPE object. This 
allows backward compatibility with a PCE that does not support the 
CLASSTYPE object. 


3.1. Object Definition 


The CLASSTYPE object contains a 32-bit word PCEP common object header 
defined in [RFC5440] followed by another 32-bit word object body as 
shown in Figure 1. 


0 1 2 3 
goi 2 IA rO T O Ia OT 2 Br 45, 6s SE 8 SA Ua Ka 3: cA O 7 289 OL 
Foto AA KAA AA Ka tata tata toto tate Aa AA Ka AA ita tata tate AA KA Aa Ka AWA KA 
| PCEP common header | 
AA Na AA KA AA Ka AA AA KA Ka Aa AA aa Aa Aa Ka AA KA Aa AA KA AA Ka Aa AA Ka Ka WA KA 
| Reserved cr | 
AA AA AA KA AA Ka AA AA KA Wa AA AA KA Aa AA Ka AA KA AA AA KA AA SA KA AA KA Aa Ka WA KA 


Figure 1: CLASSTYPE object format 
The fields in the common object header are processed as specified in 
[RFC5440]. The values of object class and object type are 22 and 1, 
respectively. If included, the CLASSTYPE object must be taken into 
account by the PCE. As such, the P flag MUST be set. The I flag is 
ignored. 


The CLASSTYPE object body contains the following fields: 


CT: 3-bit field that indicates the Class-Type. Values allowed are 1, 
2, ... , 7. The value of 0 is Reserved. 


Reserved: 29-bit reserved field. It MUST be set to zero on 
transmission and MUST be ignored on receipt. 


3.2. Path Computation Request Message with CLASSTYPE Object 
[RFC5440] specifies the order in which objects must be inserted in 


the PCEP messages. This document specifies that the CLASSTYPE object 
be inserted after the END-POINT objects as shown below: 
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The format of a Path Computation Request (PCReq) message is as 


follows: 
<PCReq Message>::= <Common Header> 
[<SVEC-list>] 
<request-list> 
where: 
<svec-list>::=<SVEC>[<svec-list>] 
<request-list>::=<request>[<request-list>] 
<request>::= <RP> 
<END-POINTS> 
[<CLASSTYPE>] 
[<LSPA>] 
[<BANDWIDTH> ] 
[<metric-list>] 
[<RRO> ] 
[<IRO>] 
[<LOAD-BALANCING> ] 
where: 
<metric-list>::=<METRIC>[<metric-list>] 


Note that an implementation MUST form the PCEP messages using the 
object ordering rules specified using Backus-Naur Form. Please refer 
to [OBJ-ORD] for more details. 


3.3. Processing CLASSTYPE Object 


If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC 
originating the PCReq MUST include the CLASSTYPE object in the PCReq 
message with the Class-Type (CT) field set to N. 


If a path computation request contains multiple CLASSTYPE objects, 
only the first one is meaningful; subsequent CLASSTYPE object (s) MUST 
be ignored and MUST NOT be forwarded. 


If the CLASSTYPE object is not present in the path computation 
request message, the LSR MUST associate the Class-Type 0 to the LSP. 


A path computation reply message MUST NOT include a CLASSTYPE object. 
If a PCE needs to forward a path computation request containing the 
CLASSTYPE object to another PCE, it MUST store the Class-Type of the 
TE LSP in order to complete the path computation when the path 
computation reply arrives. 


A PCE that does not recognize the CLASSTYPE object MUST reject the 
entire PCEP message and MUST send a PCE error message with Error- 
Type="Unknown Object" or "Not supported object", defined in 
[RFC5440]. 


Sivabalan, et al. Standards Track [Page 5] 


RFC 5455 DS Aware CT Object for PCEP March 2009 


A PCE that recognizes the CLASSTYPE object, but finds that the P flag 
is not set in the CLASSTYPE object, MUST send PCE error message 
towards the sender with the error type and error value specified in 
[RFC5440]. 


A PCE that recognizes the CLASSTYPE object, but does not support the 
particular Class-Type, MUST send a PCE error message towards the 
sender with the error type "Diffserv-aware TE error" and the error 
value of "Unsupported Class-Type" (Error-value 1). 


A PCE that recognizes the CLASSTYPE object, but determines that the 
Class-Type value is not valid (i.e., Class-Type value 0), MUST send a 
PCE error towards the sender with the error type "Diffserv-aware TE 
error" and an error value of "Invalid Class-Type" (Error-value 2). 


3.4. Determination of Traffic Engineering Class (TE-Class) 


As specified in RFC 4124, a CT and a preemption priority map toa 
Traffic Engineering Class (TE-class), and there can be up to 8 
TE-classes. The TE-class value is used to determine the unreserved 
bandwidth on the links during path computation. In the case of a 
PCE, the CT value carried in the CLASSTYPE object and the setup 
priority in the LSP Attribute (LSPA) object are used to determine the 
TE-class corresponding to the path computation request. If the LSPA 
object is absent, the setup priority is assumed to be 0. 


3.5. Significance of Class-Type and TE-Class 


To ensure coherent DS-TE operation, a PCE and a PCC should have a 
common understanding of a particular DS-TE Class-Type and TE-class. 
If a path computation request crosses an Autonomous System (AS) 
boundary, these should have global significance in all domains. 
Enforcement of this global significance is outside the scope of this 
document. 


3.6. Error Codes for CLASSTYPE Object 
This document defines the following error type and values: 
Error-Type Meaning 
12 Diffserv-aware TE error 
Error-value=1: Unsupported Class-Type 
Error-value=2: Invalid Class-Type 


Error-value=3: Class-Type and setup priority do 
not form a configured TE-class 
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4. Security Considerations 


This document does not introduce new security issues. The security 
considerations pertaining to PCEP [RFC5440] remain relevant. 


5. IANA Considerations 
IANA maintains a registry of parameters for PCEP. This contains a 
sub-registry for PCEP objects. IANA has made allocations from this 
registry as follows: 
Object-Class Name Reference 
22 CLASSTYPE RFC 5455 
Object-Type 
1: Class-Type RFC 5455 


IANA has allocated error types and values as follows: 


Error-Type Meaning Reference 
12 Diffserv-aware TE error RFC 5455 
Error-value = 1: RFC 5455 


Unsupported Class-Type 
Error-value = 2: RFC 5455 
Invalid Class-Type 
Error-value = 3: RFC 5455 


Class-Type and setup priority 
do not form a configured TE-class 
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